home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 12731 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  1.8 KB
  1. Path: EU.net!sun4nl!ittpub!ittpub!nntp
  2. Newsgroups: comp.lang.c++
  3. Subject: Re: Exception Overhead
  4. Message-ID: <1996Mar21.131518.1809@ittpub>
  5. From: wil@ittpub.nl (Wil Evers)
  6. Date: 21 Mar 96 13:15:18 WET
  7. References: <31504001.27D7@datalytics.com>
  8. Distribution: world
  9. Nntp-Posting-Host: lintilla
  10.  
  11. In article <31504001.27D7@datalytics.com> Rob Stewart  
  12. <stew@datalytics.com> writes:
  13.  
  14. > hfreeman wrote:
  15. > > 
  16. > > When my apps throw exceptions, it is in truly exceptional situations,
  17. > > thus, I'm not overly concerned about performance when exceptions are
  18. > > thrown, but could someone please speak to the performance hits taken
  19. > > when exceptions are used but not thrown (ie. when try blocks are
  20. > > entered and exited). If a try block is used in a loop, is there a
  21. > > serious performance penalty.
  22. > > 
  23. > > Thanks.
  24. > 
  25. > The performance hit is implementation-dependent. The compiler 
  26. > has to track which objects to destruct when an exception is 
  27. > thrown at any point within a function, so just enabling 
  28. > exception support invokes this overhead.
  29.  
  30. That would be an overhead at compile time, not at run time.
  31.  
  32. > A try block shouldn't incur much overhead, but I don't think it can
  33. > incur zero overhead.  As a result, you should always minimize your 
  34. > try/catch blocks--keeping them out of loops, for example.
  35.  
  36. This is not necessarily true. There are implementations around that incur  
  37. no speed penalty as long as no exceptions are thrown. These  
  38. implementations have tables to determine what code to call to do stack  
  39. unwinding, based on the address in the code where the exception is thrown.  
  40. Of course, these tables take up space, but some linkers put these tables  
  41. in a separate memory region. As a result, there will be no extra virtual  
  42. memory management overhead as long as you don't throw an exception.
  43.  
  44. - Wil
  45.  
  46.  
  47.  
  48.  
  49.